home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 94-05.Z / 94-05 / text0188.txt < prev    next >
Encoding:
Text File  |  1994-05-31  |  15.4 KB  |  353 lines

  1.  
  2. In a previous article, spere@kyrre.hsv.no (P. Eivind Jenssen) says:
  3.  
  4. >We are having trouble with FD_READ and FD_WRITE messages!
  5. >We would like to use the function WSAAsyncSelect() this way:
  6. >      WSAAsyncSelect(s, hWnd, READ_OR_WRITE, FD_READ | FD_WRITE);
  7. >
  8. >The READ_OR_WRITE message calls a function of ours.
  9. >Our question is:
  10. >     Can one find out in this function if it was an FD_READ
  11. >     or an FD_WRITE that called the function?
  12. >
  13.  
  14.  
  15.     I don't have the specs in front of me but I think the way it works
  16. is:
  17.  
  18.     Msg will be READ_OR_WRITE
  19.     wParam = socket id
  20.     lParam = LOWORD() = FD_xxxx
  21.          HIWORD() = error code
  22.  
  23.     So LOWORD(lParam) should be FD_READ or FD_WRITE as you need.
  24.  
  25. -- 
  26. +--------------------------------------------------------------------------+
  27. | Michael Comet, mbc@po.CWRU.Edu - CWRU, Software Engineer/Graphics Artist |
  28. | Computer Graphics/Animation! - Liquid Vision SIG (go liquid),  Freenet   |
  29. +--------------------------------------------------------------------------+
  30. From news@bigblue.oit.unc.edu Fri May 13 13:45:18 1994
  31. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  32.           id AA06943; Fri, 13 May 1994 13:45:18 -0400
  33. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  34.           id AA34152; Fri, 13 May 1994 13:44:19 -0400
  35. Received: from GATEWAY by bigblue with netnews
  36.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  37. To: winsock@sunsite.unc.edu
  38. Date: Fri, 13 May 1994 12:56:56
  39. From: overbyte@acy.digex.net (overbyte)
  40. Message-Id: <overbyte.7.000CF34F@acy.digex.net>
  41. Organization: Shakedown Productions
  42. Sender: ses
  43. References: <cpunk.13.000DDDBE@halcyon.com>, <robert.396.00175A62@clark.net>, <Cpq5v5.3HJ@ucdavis.edu>
  44. Subject: Re: is it me or does wintalk stink?
  45.  
  46. In article <Cpq5v5.3HJ@ucdavis.edu> jhframe@ucdavis.edu (Jim Frame) writes:
  47. >From: jhframe@ucdavis.edu (Jim Frame)
  48. >Subject: Re: is it me or does wintalk stink?
  49. >Date: Fri, 13 May 1994 04:59:28 GMT
  50.  
  51. >In article <robert.396.00175A62@clark.net>, robert@clark.net (Robert Seidman) says:
  52. >>It works fine for me, incoming and outgoing.  I'm not sure what your setup
  53. >>is, so I can't offer any advice.  I'm very happy with it...but I do
  54. >>wonder about the icon too! 
  55.  
  56. >I've only used it outgoing, and have but one complaint (aside from the
  57. >obnoxious icon):  the incoming window has no cursor, so I have no 
  58. >indication as to whether or not the other party has paused at the end
  59. >of a line, or issued a couple of returns (I've only used talk with one
  60. >other person, and we "yield the floor" by sending two blank lines).
  61.  
  62. >Once the incoming window is full, I can tell by the fact that the screen
  63. >scrolls upward that a return has been sent; but until that time, I have 
  64. >to resort to guesswork.
  65.  
  66.  I havent had a problem with it. & being its a split screen ansi like chat 
  67. that hold cursor possition i dont worry about typing while the other person 
  68. is... 
  69.  
  70.  
  71.              -The futures here, we are it, we are on our own.
  72.                    Mail via POP Overbyte@acy.digex.net
  73.                           SLIP @lamer.digex.net
  74. From news@bigblue.oit.unc.edu Fri May 13 17:25:55 1994
  75. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  76.           id AA06963; Fri, 13 May 1994 13:45:21 -0400
  77. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  78.           id AA19301; Fri, 13 May 1994 13:43:00 -0400
  79. Received: from GATEWAY by bigblue with netnews
  80.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  81. To: winsock@sunsite.unc.edu
  82. Date: Fri, 13 May 1994 17:25:55 GMT
  83. From: arnstein@netcom.com (David Arnstein)
  84. Message-Id: <arnsteinCpr4F7.HCJ@netcom.com>
  85. Organization: My Own Internet Account!
  86. Sender: ses
  87. References: <1994May12.155317.3383@megatek.com>, <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>
  88. Reply-To: arnstein@netcom.com
  89. Subject: Re: 32 bit access with SCSI no available. Hunh? was Re: Win Mosaic alpha 4 (my fix)
  90.  
  91. In article <CppIL6.vK@nntpa.cb.att.com>,
  92. na8520d00-Nichols <rnichols@ihlpm.ih.att.com> wrote:
  93. >In article <arnsteinCppEAr.L72@netcom.com>,
  94. >>Windows 3.1 users:
  95. >>
  96. >>    ***   J U S T    S A Y    N O    T O    S C S I   ***
  97. >
  98. >You keep repeating this litany over and over, perhaps expecting it to
  99. >become true by repetition alone.
  100. >
  101. >Windows can run just fine on SCSI system, and the presence or absence
  102. >of 32-bit access has little effect on the performance.  I run Windows
  103. >on a SCSI system with no performance problems whatsoever.
  104.  
  105. Put your money where your mouth is.  Find yourself a peecee with your
  106. favorite SCSI host adapter and disk drive, and an IDE drive of recent
  107. vintage.  Run WinBench 4.0 to obtain disk timings on each drive.  I
  108. did.  That's how I came to my conclusion:  just say no to SCSI!  I've
  109. corresponded with plenty of folks who say "I'm using SCSI and it
  110. works just fine, thank you."  But if your expensive SCSI hardware
  111. doesn't decisively outperform an IDE disk, you've wasted your time
  112. and money.
  113.  
  114. >If you are accessing your SCSI disk via the SCSI BIOS, though, you may
  115. >indeed have a major performance problem.  For a busmastering SCSI
  116. >adapter, this implies that you are using the double-buffering function
  117. >of SMARTDrive, which will turn the fastest system into a dog.  (This
  118. >was the case on my own system, as the manufacturer configured it.) 
  119. >What you desperately need is an ASPI driver that either (a) supports
  120. >the virtual DMA interface directly, or (b) provides the necessary
  121. >buffering itself.  This will allow you to get rid of the SMARTDRV
  122. >/DOUBLE_BUFFER line in your CONFIG.SYS.  Furthermore, the SCSI BIOS is
  123. >no longer used once the ASPI driver is installed.  This eliminates
  124. >another performance bottleneck since it is often impossible to enable
  125. >shadowing for the SCSI BIOS, forcing the CPU to run directly from the
  126. >8-bit EPROM.  (In busmastering controllers, a portion of this address
  127. >range is used as a mailbox and must be writable.  Most motherboards do
  128. >not allow you to shadow a range of addresses and still be able to
  129. >perform writes there.)
  130.  
  131. I have a Future Domain SCSI host adapter.  It does not do
  132. busmastering, it uses programmed I/O (PIO).  Therefore, I don't need
  133. double buffering.  I don't use it.  If your ASPI driver is a DOS TSR,
  134. it must still run in real mode, so you're still paying the (large)
  135. performance penalty for switching between protected mode and real
  136. mode.  By the way, busmastering SCSI host adapters cause problems
  137. when used with floppy port tape drives (QIC 40 and QIC 80 standard).
  138. This is because of the crappy support for DMA provided by the
  139. industry standard architecture.  If you use such a tape drive, you'll
  140. have to fiddle with the "bus on" time of your SCSI host adapter,
  141. complicating your life and further degrading SCSI I/O speed.
  142.  
  143. Maybe I should ditch my Future Domain h.a. in favor of Adaptec,
  144. apparently that's what you're using.  But Adaptec is expensive, and
  145. the magazine reviews I've seen indicate that the Future Domain 1680
  146. (my h.a.) is a speedy product.
  147.  
  148. >If you cannot obtain a driver that will permit you to eliminate
  149. >SMARTDrive's double buffering, then I would have to agree with your
  150. >"JUST SAY NO" advice -- for that particular SCSI adapter, anyway.
  151. >
  152. >(BTW, to the best of my knowledge, the ASPI drivers in the
  153. >CorelSCSI! package do NOT allow you to eliminate SMARTDrive's double
  154. >buffering.  Adaptec's ASPI4DOS has a switch to provide the necessary
  155. >buffering itself, as do the drivers for DTC's busmastering SCSI
  156. >adapters.  For the Buslogic BT747S, the drivers perform the necessary
  157. >functions automatically, with no explicit switch required.  I have no
  158. >experience with other SCSI adapters.)
  159. -- 
  160. David Arnstein       |          What do you mean, "get a life"?
  161. arnstein@netcom.com  |          This *is* my life!
  162. From news@bigblue.oit.unc.edu Fri May 13 14:15:10 1994
  163. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  164.           id AA13623; Fri, 13 May 1994 14:15:10 -0400
  165. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  166.           id AA34154; Fri, 13 May 1994 13:45:14 -0400
  167. Received: from GATEWAY by bigblue with netnews
  168.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  169. To: winsock@sunsite.unc.edu
  170. Date: Fri, 13 May 1994 12:59:33
  171. From: overbyte@acy.digex.net (overbyte)
  172. Message-Id: <overbyte.8.000CFE75@acy.digex.net>
  173. Organization: Shakedown Productions
  174. Sender: ses
  175. References: <2qv4hk$161f@inca.gate.net>, <2qvtlj$5e5@news.csie.nctu.edu.tw>
  176. Subject: Re: alt.winsock.binaries???
  177.  
  178. In article <2qvtlj$5e5@news.csie.nctu.edu.tw> jenwen@pdd.iii.org.tw (Jenwen) writes:
  179. >From: jenwen@pdd.iii.org.tw (Jenwen)
  180. >Subject: Re: alt.winsock.binaries???
  181. >Date: 13 May 1994 13:00:35 GMT
  182.  
  183. >Nickolas (Nickolas@inca.gate.net) wrote:
  184. >: Hello people,
  185. >: 
  186. >:    I was thinking how  about making a group for binary posting?
  187. >: It would better for some one who wants to release there winsock
  188. >: software. Just a thought ;)
  189. >: 
  190. >:     Nickolas@inca.gate.net
  191.  
  192. >I agree!! Since it seem so many ask where Trumpet? where ..
  193.  
  194. >Jenwen,Chien-Wen Huang
  195. >jenwen@netrd.net.tw 
  196.  
  197.  I secound that! I think a WINSOCK only binary groupe would be great since
  198. most of thew stuff is beta & buggy why mix it up in an enormous news group. 
  199. leave it specialized...
  200.  
  201.              -The futures here, we are it, we are on our own.
  202.                    Mail via POP Overbyte@acy.digex.net
  203.                           SLIP @lamer.digex.net
  204. From news@bigblue.oit.unc.edu Fri May 13 17:30:11 1994
  205. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  206.           id AA13633; Fri, 13 May 1994 14:15:12 -0400
  207. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  208.           id AA12213; Fri, 13 May 1994 13:52:17 -0400
  209. Received: from GATEWAY by bigblue with netnews
  210.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  211. To: winsock@sunsite.unc.edu
  212. Date: Fri, 13 May 1994 17:30:11 GMT
  213. From: arnstein@netcom.com (David Arnstein)
  214. Message-Id: <arnsteinCpr4MC.HL5@netcom.com>
  215. Organization: My Own Internet Account!
  216. Sender: ses
  217. References: <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>, <2quet0$8u3@bmerha64.bnr.ca>
  218. Reply-To: arnstein@netcom.com
  219. Subject: Re: 32 bit access with SCSI not avail. -> Adaptec questions.
  220.  
  221. In article <2quet0$8u3@bmerha64.bnr.ca>, Jeff Hayes <jjhayes@bnr.ca> wrote:
  222. >
  223. >_]What you desperately need is an ASPI driver that either (a) supports
  224. >_]the virtual DMA interface directly, or (b) provides the necessary
  225. >_]buffering itself.  This will allow you to get rid of the SMARTDRV
  226. >_]/DOUBLE_BUFFER line in your CONFIG.SYS. 
  227. >    Adaptec docs say to remove the /DOUBLE_BUFFER, set VirtualHDIRQ=off
  228. >in system.ini to make everything happy in Windows.
  229. >
  230. >_]Adaptec's ASPI4DOS has a switch to provide the necessary
  231. >_]buffering itself
  232. >    I have the Adaptec docs here in front of me and there is no
  233. >switch to enable buffering in aspi4dos.  Neither do any of the other 3
  234. >drivers.  Hummm.
  235. >
  236. >    So...
  237. >
  238. >    The questions to answer (Adaptec's docs do not) are:
  239. >
  240. >    Do the Adaptec drivers support VDMA?
  241. >    Do they do there own buffering?
  242. >    Is there buffering cache on the ctlr board?
  243.  
  244. Just listen to all this complexity!  If you have the guts, do a
  245. quantitative comparison of speed of your SCSI nightmare with an IDE
  246. drive - while running Windows 3.1.  Have you gained any speed?
  247. -- 
  248. David Arnstein       |          What do you mean, "get a life"?
  249. arnstein@netcom.com  |          This *is* my life!
  250. From news@bigblue.oit.unc.edu Fri May 13 15:27:41 1994
  251. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  252.           id AA13648; Fri, 13 May 1994 14:15:15 -0400
  253. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  254.           id AA19019; Fri, 13 May 1994 14:12:14 -0400
  255. Received: from GATEWAY by bigblue with netnews
  256.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  257. To: winsock@sunsite.unc.edu
  258. Date: Fri, 13 May 94 15:27:41 GMT
  259. From: cbarton@clark.dgim.doc.ca (Casey Barton)
  260. Message-Id: <cbarton.115.2DD39C6A@clark.dgim.doc.ca>
  261. Organization: None
  262. Sender: ses
  263. References: <toreh.24.2DC76C31@bootes.sds.no>, <jones.35.0017A7E6@cbdb1.nimh.nih.gov>, <toreh.1.2DD37539@bootes.sds.no>
  264. Subject: Re: The purpose of this news group: netsurfing?
  265.  
  266. toreh@bootes.sds.no (Tore Haraldsen) writes:
  267. >Well, since this news group started out as a continuation of the 
  268. >corresponding winsock mailing-list, I do not think my question was 
  269. >impertinent. This group WAS alt.winsock.programming!
  270.  
  271.     Well, it underwent a spontaneous name change then. It now seems to be 
  272. called alt.winsock.
  273.  
  274. >This group WAS supposed to be the forum for specialized questions around 
  275. >winsock programming.
  276.  
  277.     Regardless of initial intentions, this group is now fulfilling a useful 
  278. niche -- winsock applications are probably the single fastest growing group of 
  279. internet access software around, and a common forum for discussion is useful. 
  280. In fact, I believe that a comp.*.winsock would be fully justified...
  281.  
  282.     A group specifically for winsock *programming* should, logically, be 
  283. called *.winsock.programming, no?  There's certainly a demand for it. Why 
  284. don't you initiate the process of creating it, instead of stating that nearly
  285. everybody that is making good use of this group should be somewhere else?
  286.  
  287. >What I was trying to say (and maybe I did not make it clear enough), is the 
  288. >obvious lack of a news group for connectivity & utilities discussions. This 
  289. >group is not the only one , others being comp.protocol.nfs, 
  290. >comp.protocol.tcpip.* etc.
  291. >
  292. >So I tried to suggest  we need a specialized group for connectivity & 
  293. >utilities: alt.winsurf or alt.netsurf may be.
  294.  
  295.     But the bulk of non-programming-related posts here are not simply generic 
  296. "netsurfing" questions -- they are *winsock* specific. So they certainly have 
  297. a place here.  Perhaps a generic "netsurf" group would be useful as well, 
  298. though I suspect that alt.netsurf is a little too generic. At any rate, any 
  299. such group should be created in *addition* to this group, not in place of it.
  300. +-----------------------------------------------------------------------------+
  301. |          Casey Barton (a guy)            cbarton@clark.dgim.doc.ca          |
  302. |              http://pctcp132.dgcp.doc.ca/personal/index.html                |
  303. From news@bigblue.oit.unc.edu Fri May 13 16:30:03 1994
  304. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  305.           id AA21702; Fri, 13 May 1994 14:45:10 -0400
  306. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  307.           id AA23923; Fri, 13 May 1994 14:21:02 -0400
  308. Received: from GATEWAY by bigblue with netnews
  309.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  310. To: winsock@sunsite.unc.edu
  311. Date: Fri, 13 May 1994 16:30:03 GMT
  312. From: cpm@uplx.co.uk (Chris P Murray)
  313. Message-Id: <Cpr1u5.6pI@uniplex.co.uk>
  314. Organization: Uniplex Ltd.
  315. Sender: ses
  316. References: <2qtem9$il3@debbie.cc.nctu.edu.tw>
  317. Subject: Re: Why connect error?
  318.  
  319. u8234514@cc.nctu.edu.tw wrote:
  320. :  sockfd = socket(AF_INET, SOCK_STREAM, 0)
  321. :  If (sockfd <= 0) Then
  322. :     MsgBox ("Open socket error!")
  323. :  End If
  324. :  dest.sin_family = AF_INET
  325. :  dest.sin_addr = inet_addr(txtHost.Text)
  326. :  dest.sin_port = htons(Val(txtPort.Text))
  327. :  destlen = 15
  328. :  If (connect(sockfd, dest, destlen) < 0) Then
  329. :     MsgBox ("Connect Error")
  330. :  End If
  331.  
  332. I'm assuming 'dest' is correctly defined as:
  333.  
  334.     struct sockaddr_in dest;
  335.  
  336. then try:
  337.  
  338.   sockfd = socket(AF_INET, SOCK_STREAM, 0)
  339.   If (sockfd < 0) Then
  340.      MsgBox ("Open socket error!")
  341.   End If
  342.   bzero((char *) &dest, sizeof(dest));
  343.   dest.sin_family = AF_INET
  344.   dest.sin_addr = inet_addr(txtHost.Text)
  345.   dest.sin_port = htons(Val(txtPort.Text))
  346.   If (connect(sockfd, (struct sockaddr *) &dest, sizeof(dest)) < 0) Then
  347.     MsgBox ("Connect Error")
  348.  
  349. (Note the 'If (sockfd < 0)' test should be '< 0' not '<= 0' as it could
  350.  return fd 0 is you've close stdin)
  351.  
  352.  
  353.